Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

Do you think the inability to add message handlers is a problem?

Do you think the inability to add message handlers is a problem?

This is for simple situations where you're just doing "new HttpClient().GetStringAsync()` today, only this lets you do it better. For anything where you need to configure anything, this isn't for you. As I raised in API review today, if we think that's a problem, we shouldn't add it, but it also makes the simple cases simpler and more streamlined. So many times when I'm writing a little tool or a benchmark or a demo or whatever, all I want to do is grab some data from something on the web, and this makes it a one-liner.

all I want to do is grab some data from something on the web, and this makes it a one-liner.

And what does

await HttpClient.Shared.GetStringAsync("https://dot.net/somefile.txt");

makes any better than:

await new HttpClient().GetStringAsync("https://dot.net/somefile.txt");

in terms of line count?! If my eyes are working correctly the amount of lines should be equal in both cases. If its the performance, you would rather create a single static httpclient you reuse (which is what is also recommended by the documentation). And this one you can also customize the way you want, if you want. But for these "small tools" you mention I doubt that performance matters at all. If you just grab something from the web, in a small tool, for a single or second time you aren't even forced to dispose the HttpClient because in real world these few bytes are not killing any machine. But if performance matters and you need to dispose the client, because it's getting called frequently. Then you'd rather do what the documentation recommends you to do.

And what does
await HttpClient.Shared.GetStringAsync("https://dot.net/somefile.txt");
makes any better than:
await new HttpClient().GetStringAsync("https://dot.net/somefile.txt");

It makes it better when you on the very next line do the same thing but for a different file, or you do this in a loop, or some such thing. It makes it better when you do this in a few different places. It makes it better in that you're not instantiating an HttpClient and thus not on the hook to track and clean up after it.

It makes it better when you on the very next line do the same thing but for a different file, or you do this in a loop, or some such thing. It makes it better when you do this in a few different places. It makes it better in that you're not instantiating an HttpClient and thus not on the hook to track and clean up after it.

Sounds great but isn't that exactly what I mentioned before? When this is important for your app, create a static readonly httpclient and use that. The docs even say so. But if that is not important which I expected when you said "its for small apps doing small things", then I still don't see how it makes it any better. It feels like its just there for "completeness". Just for having it there. But it doesn't feel like there is a real need for this. Or a real world scenario. Or it solves a real problem.

It's about making something that lots of folks need to do even easier, with greater liklihood for shared resources. If you have a helper over here that needs to grab some data, and another over there, and another over there, they don't each need to manage their own separate client or deal with DI complexities. And if you're making multiple calls even in the same component, you don't have to create a static readonly or even know you're supposed to. Simple things stay simple.

It looks simple, but there's a hidden complexity. The proposed API is good for small apps, but you can't ensure that developers of larger apps get it right.

For example, current guidelines for HttpClient recommend using singleton instance with PooledConnectionLifetime property set to some value, to avoid stale DNS usage: https://learn.microsoft.com/en-us/dotnet/fundamentals/networking/http/httpclient-guidelines#recommended-use How this issue will be solved with proposed API? If the new shared instance just uses default behaviour, with endless connection lifetime, it will be easy for people to run into exactly this issue. Some way to configure connection pooling behaviour is really needed.

I still think this is valuable, but there's enough consternation over this that I'm going to close it.